http://sendgrid.com/
http://mailchimp.com - про него подробнее: http://habrahabr.ru/company/softline/blog/144190/
http://aws.amazon.com/ses/

При попытке выполнить на проекте Team->Pull появляется сообщение об ошибке вида:
The current branch is not configured for pull
No value for key branch.XXXXXX.merge found in configuration

Решение:
1. Открыть конфиг-файл .git/config
2. Добавить описание для заданной ветки

[branch "XXXXXXXX"]
  remote = origin
  merge = refs/heads/XXXXXXX

Операция Push состоит из 2х действий:

1. Передача ранее выполненных (и ещё не "запушенных") "коммитов" из локального репозитория (хранилища) в следующее хранилище более высокого уровня (глобальное, корпоративное ...)
2. Выполнение операции Merge для отправляемых "коммитов" с веткой хранилища более высокого уровня по стратегии "fast-forward"

Стратегия "fast-forward" разрешает "сливать" ("мержить") "коммиты" только в рамках одной ветки.
По этой стратегии напрямую нельзя "коммит" из ветки1 "слить" в ветку2.

GIT - децентрализованное хранилище.
Поэтому надо учитывать, что после того, как "коммиты" попали в хранилище более высокого уровеня - их мог уже кто-то скачать, а у этого кто-то ещё кто-то ...
Поэтому хорошая и правильная практика никогда не менять историю "запушеных коммитов" на сервере.

Если к базе есть подключения, то операции удаления или переименования базы не будут проходить.

Получить список подключений можно командной:
SELECT usename, client_addr, backend_start, current_query FROM pg_stat_activity WHERE datname = 'ИМЯ_БАЗЫ_ДАННЫХ';

Коннекты можно сбросить командой:
SELECT pg_terminate_backend( procpid ) FROM pg_stat_activity WHERE procpid <> pg_backend_pid( ) AND datname = 'ИМЯ_БАЗЫ_ДАННЫХ';

При попытке выполнить update для SpringSource Tool Suite выскакивает ошибка
No repository found at http://dist.springsource.com/release/TOOLS/update/e3.*
Но в браузере по запросу на этот URL приходит в ответ некий небольшой XML.

Лечение:

• в STS зайти в Help >> Install New Software (скорее всего опять всплывёт окошко с этой же ошибкой - игнорировать его)
• нажать на ссылку "Available Software Sites"
• в открывшемся окне выбрать в списке сайтов "SpringSource Update Site for Eclipse"
• нажать кнопку [Reload]
• подождать пока пройдет апдейт
• закрыть ненужные окна

С одной стороны производители софта стонут, что слабая реализация.

А вот ситуация с другой стороны:
- есть продукт вендора (SAAS), который жёстко зашит (найти бы того архитектора) на его (вендора) доменное имя (например: service.softcloud.ru ) - т.е. любой клиент должен заходить только на этот адрес и ни какой иной.
- появился потенциально крупный потребитель на пакет из нескольких SAAS-продуктов, но которому надо, чтобы точка входа была строго на его собственном домене, т.е. не service.softcloud.ru, а service.corporation.org
- платформа управления продуктами SAAS позволяет такие штуки, но вендору надо немного разобраться в неких технологических тонкостях
- на мою просьбу "коллеги, мы не можем продать ваш товар в таком виде - допилите, пожалуйста, его немного" я получаю шедевральный ответ:

"Я бы предложил не включать наш продукт в пакет..."

Пытаюсь прикинуть разумный минимальный полезный размер в байтах для HTTP-запроса исходя из того, что HTTP-запрос ходит поверх TCP-пакетов.
Следовательно - быстрая передача - это чтобы HTTP_запрос умещался в 1 TCP-пакет.
TCP-пакет с одной стороны должен быть меньше 65кБайт (лимит IP-фрейма), а с другой стороны размер TCP-пакета - это ЗАГОЛОВОК (20...60байт) + ТЕЛО любой длины, но в сумме не больше MTU.
Значени MTU, как я понимаю, могут быть на маршруте разными, но по RFC 879 минимальный размер 576 байт.
Поэтому получается, что минимальны размер полезных данных в HTTP-запросе равен 576 байт минус 60 байт на заголовок TCP-пакета, минус длина HTTP-заголовка. А т.к. минимальный HTTP-заголовок по моим субъективным ощущениям в среднем около 300-400 байт, то получается, что на полезные данные остается минимально 100-200 байт.
Есть ли ошибки в рассуждениях?